home *** CD-ROM | disk | FTP | other *** search
- Path: news.uit.no!news
- From: nilss@stud.cs.uit.no (Nils Peter Sudmann)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Removing a patch - solved?
- Date: 01 Feb 96 21:50:50 +0100
- Organization: University of Tromsoe, Norway
- Message-ID: <1128.6605T1310T2548@stud.cs.uit.no>
- References: <1996Jan22.150212.23377@ludens> <4e1p58$4l2@misery.millcomm.com>
- <815.6602T1142T756@norconnect.no> <1433.6603T1100T1439@stud.cs.uit.no> <slrn4h17b3.5rq.ing9435@xerxes.to.mh.se>
- NNTP-Posting-Host: uit-or6.uit.no
- X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
-
- On 01-Feb-96 12:01:01, Jimmy Westerlund (ing9435@ind.mh.se) wrote:
- >In article <1433.6603T1100T1439@stud.cs.uit.no>, Nils Peter Sudmann wrote:
-
- >> The problem is that some program
- >>could be executing inside your patched code (and currently waiting for a
- >>time slice). AFAIK there is *no* way to safely know when the last thread of
- >>control has left your code (and you may unload it). So a patch should
- >>actually never remove itself (only render itself inactive). I did miss the
- >>previous patch discussion, but I wrote one myself and came to the above
- >>conclusion. Right or wrong?
-
- > Wouldn't this work:
-
- > patch:
- > addq.l #1,counter
-
- > ; Patch stuff
-
- >exit_patch:
- > subq.l #1,counter
- > rts
-
- Nope, if a task-switch occurs just after the jump to 'patch:' *but* before the
- addq, you're sold. Same goes for the subq -> rts. I'ill agree that the odds of
- this happening are pretty small. But it is not *correct*.
-
- --
- Nils Peter Sudmann // Using Thor v2.21/#1113, sign v1.5
- "Truth, a random variable possibly // EMAIL: nilss@stud.cs.uit.no
- containing complex numbers" // WWW: http://www.cs.uit.no/~nilss
-
-
-